As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
In the course of operation, various information handling resources (e.g., components of an information handling system) may become crashed, hung, or otherwise failed. The ability to reset such information handling resources may thus increase the operational reliability of information handling systems.
As one example, serial peripheral interface (SPI) read-only memories (ROMs) are a type of information handling resource on which many functions rely. In some embodiments, a SPI ROM may itself be a component of an information handling resource within an information handling system. A SPI ROM may control various aspects of data storage and code execution in such an information handling resource. In various embodiments, such SPI ROMs may be programmable ROMs (PROMs), erasable programmable ROMs (EPROMs), or electrically erasable programmable ROMs (EEPROMs). For sake of clarity and exposition, all such variants are referred to simply as SPI ROMs herein.
A SPI ROM may encounter various types of failure modes. For example, hardware-based malfunctions may be caused by spurious power or ground noise transients. Further, a device that is being operated beyond the limits of its specifications may operate marginally, experiencing partial or total failure.
Other malfunctions may be caused by software or firmware issues. For example, a SPI ROM may receive incorrect opcodes that put it into the wrong operating mode (e.g., quad I/O width when the bus is only configured for single I/O), or undocumented opcodes that put it into a diagnostic or test mode. As another example, an incorrect clock frequency change beyond the device's specifications may also cause a failure. As yet another example, a SPI ROM may contain a defect in its internal firmware that can cause instability or malfunctions.
When a SPI ROM enters a failure mode, it may be advantageous to be able to reset it. Although such a reset may be accomplished by resetting the entire information handling system (or information handling resource) that comprises the SPI ROM, doing so may not always be desirable. In particular, in some embodiments, it may be desired to leave most of such a system functional and/or leave an auxiliary power enabled while in the process of resetting the SPI ROM.
Unfortunately, the SPI ROM may not include an input specifically useable for causing a full reset. Thus it may be desirable to cause a more complete reset than what is available via the standard SPI ROM inputs.
This disclosure provides various techniques that may be employed in these and other situations.